Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold
3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (378248d) 97.29% compared to head (83f363d) 97.28%.
Report is 31 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #1453      +/-   ##
===========================================
- Coverage    97.29%   97.28%   -0.01%     
===========================================
  Files          133      132       -1     
  Lines         3396     3392       -4     
  Branches      1038     1038              
===========================================
- Hits          3304     3300       -4     
  Misses          87       87              
  Partials         5        5              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

1. @kb-0311
2. @vasujain275
3. @EshaanAgg

Please take a look and comment. You have been involved with Docker updates to the repos in the recent past

Merge your code with the latest upstream. The introspection tests should be passing.

Hey @palisadoes,
There's already an PR for script.ts #1350 , so should i work on it once its merged to avoid merge conflicts?

Hey @palisadoes, There's already an PR for script.ts #1350 , so should i work on it once its merged to avoid merge conflicts?

That should be merged in a day or two

@Devesh326 @palisadoes

Wouldn't it be better to push the talawa-admin image to Docker Hub or any public Docker repository and then use that image in the docker-compose file for talawa-api? This way, the talawa-admin container will be in the same Docker network/group with other containers such as mongo, redis, and the talwa-api container. We can have a CI/CD pipeline to push a new image to Docker Hub on every merge, which can be pulled by the docker-compose file in the talawa-api repo.

@Devesh326 @palisadoes

Wouldn't it be better to push the talawa-admin image to Docker Hub or any public Docker repository and then use that image in the docker-compose file for talawa-api? This way, the talawa-admin container will be in the same Docker network/group with other containers such as mongo, redis, and the talwa-api container. We can have a CI/CD pipeline to push a new image to Docker Hub on every merge, which can be pulled by the docker-compose file in the talawa-api repo.

While @palisadoes can provide additional insights but in my opinion

1. This would increase the build/execution time for talawa-api.
2. Definitely including docker image for talawa-admin would reduce installation/execution complexity but is there any other specific reason for both to be on the same network?

Pls correct me if i am wrong.

1. Please fix the conflicting files
2. The setup script PR has been merged. You can add the script updates to this PR

I'm not very familiar with Docker Hub but it appears to be similar to an app store.

1. The repos are too dynamic to have such a tight coupling between Admin and API.
2. We are constantly adding and removing features in one and/or the other.
3. This is something we can consider later when:
   1. the compatibilities between the two are more stable.
   2. we feel confident that the main branches are ready for Alpha and Beta testing.

The short term aim of dockerization is to make life of the developer less complicated in getting the app setup.

@palisadoes @Devesh326

1. Yes, I agree; it is better to have separate docker-compose files for talawa-api and talawa-admin for now.
2. Once this PR is merged, we can create a different PR for setting up a github workflow to push these images to Docker Hub.
3. Once the Docker Hub CI/CD pipeline is working, we can provide developers setting up talawa-api using Docker Compose an option parameter to also run talawa-admin by using the Docker Hub image.
4. This will especially help talawa mobile app developers, as they can run both talawa-api and talawa-admin from the Docker Compose file of the talawa-api repo by passing an optional argument to the docker-compose up command.

Hey @palisadoes,

When I committed the changes my forked branch says 7 files changed, but here it shows 232 files changed, maybe its showing the changed files of the setup script PR since it was mentioned here.

So should i make a new PR or this is fine?

Hey @palisadoes,

If any changes are required please let me know!

Hey @palisadoes,

When I committed the changes my forked branch says 7 files changed, but here it shows 232 files changed, maybe its showing the changed files of the setup script PR since it was mentioned here.

So should i make a new PR or this is fine?

The documentation file bug has been fixed.

1. Create a branch based on the current upstream
2. zip the files in the documentation directory for this branch
3. Use the PR branch
4. unzip the documentation over documentation directory
5. Commit the changes

Merging with your upstream should have no conflicts

@kb-0311 @vasujain275 Is this ready to merge? I'm not familiar with docker.

@Devesh326 Please fix the PR, how is this changing 232 files?

@Devesh326

1. Implement a multi-stage build for the Docker container.
2. Instead of including all the source code and Node modules in the Docker container, it should only contain build files and serve from that production build.
3. You can reference this example from here - https://www.fl0.com/blog/the-perfect-multi-stage-dockerfile-for-node-js-apps.
4. I am following the same approach and will refactor the talawa-api Dockerfile too once the cloud instance scripts are done, as it is more efficient and offers significant performance and security advantages.

@vasujain275

yeah i dont know why it was showing 232 files changed, merging with the latest upstream fixed it.

@Devesh326

1. Implement a multi-stage build for the Docker container.
2. Instead of including all the source code and Node modules in the Docker container, it should only contain build files and serve from that production build.
3. You can reference this example from here - https://www.fl0.com/blog/the-perfect-multi-stage-dockerfile-for-node-js-apps.
4. I am following the same approach and will refactor the talawa-api Dockerfile too once the cloud instance scripts are done, as it is more efficient and offers significant performance and security advantages.

Sure Great Idea!

Hey @palisadoes,

When I committed the changes my forked branch says 7 files changed, but here it shows 232 files changed, maybe its showing the changed files of the setup script PR since it was mentioned here.

So should i make a new PR or this is fine?

The documentation file bug has been fixed.

1. Create a branch based on the current upstream
2. zip the files in the documentation directory for this branch
3. Use the PR branch
4. unzip the documentation over documentation directory
5. Commit the changes

Merging with your upstream should have no conflicts

This is how you fix the 200+ file issue.

We had a bug in one of our GitHub actions

This is how you fix the 200+ file issue.

We had a bug in one of our GitHub actions

Yeah now its resolved, i just merged the upstream branch and now its fixed!!

Noted for future reference, thanks!

@kb-0311 @vasujain275 PTAL once more

@palisadoes

This pr is not ready to merge yet, @Devesh326 is implementing the different and more efficient method for Dockerfile, once those changes are committed I will review them and let you know

I'm in the process of implementing a multi-stage build, which is a bit new concept for me. I'm currently familiarizing myself with how it works and plan to commit the changes in the next couple of days.

This pull request did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed. Mention it now if you need help or give permission to other people to finish your work.

Closing due to inactivity